coverage: 93.422% (-0.04%) from 93.46%
when pulling 67b7a5d on herbarium-form-modal
into 3b7e193 on main.

@mo-nathan @JoeCohen Please take a minute to test this manually at two places:

• herbaria/new the usual place for creating a fungarium. The thing that needs testing is creating a new Location during the process of filling out the form.
• observations/new. If you click "has_specimen" you should see a link to "create fungarium" above the name of your default fungarium. This will open a pop-up modal form just like the above, where you should be able to
  • create a new location for a fungarium
  • create the fungarium
  • find the brand new fungarium filled in on the create obs form.

Fungaria is admittedly a minor use case, but I would like to roll this UI out also for Projects and User Profiles, potentially reducing a step in both of these forms.

Very slick. Picks up lots of stuff automatically.
Problem: clicking Create Locality does not create the Locality. So it gets stuck in the Create New Fungarium modal when trying to Create Locality while creating new Herbarium while creating an Obs.
What I did:

• Create Observation
• Drag 2 photos (Love how this works with automatically getting the date & location.
• Folded Images + Details.
• In Identification + Specimen::
  • Filled in Scientific Name, selected Confidence, checked Specimen Available.
    Result: The section expanded.
  • Clicked Create New Fungarium. (I left the Fungarium Name ("Joseph D. Cohen personal herbarium") alone. I didn't fill in Collector's Number, Accession Number or Fungarium Record Notes.)
    Result: Opened Create New Fungarium modal. In that modal:
    • Filled in Name
    • Did NOT check personal fungarium box.
    • In Location, typed non-existent Location (McMinnville, Yamhill Co., Oregon, USA)
      Result: Create locality button appears. NIce! (Do you want to capitalize "locality"?)
    • Clicked Create locality
      Result: Map appears with correct bounding box. Create locality match found check icon appears. But the locality is not created. (I looked in the Rails console.)
    • Clicked Create button.
      Result: No visible change. (It now creates the Locality, without notifying user. It does not create the Herbarium.)
      What now? I'm apparently stuck in the Create New Fungarium modal, with no way out.

Joe,
I heard about all that mushroom rustling up in McMinnville, and I put two and two together, and, well... this was the only way I knew to bring the suspect to justice.

I'm afraid you'll have to wait here in the modal until the sheriff comes.

Thanks Joe for all the feedback. I’m just trying out the flow you did, and i get a different result, when i click “Create” on the fungarium modal:

• A flash in the create obs form, with three success messages
  
• The new fungarium name now filled out in the form. (It should probably remove the “Create” button at this point, I’m realizing.)
  

I spent a while on the Create Fungarium stuff inside the Create Observation stuff and my assessment is that it isn’t worth it. The use case I spent the most time on was creating an observation that I want to deposit at the MBLWHOI Library Herbarium (see https://mblwhoilibrary.org/special-collections/mblwhoi-library-herbarium/). The first issue I ran into is that it isn’t clear from the Create Observation UI whether the fungarium/herbarium even exists when I enter the name for it. Given that it doesn’t seem worth adding to the Create Observation workflow. Creating a fungarium should be a rare event. I don’t see the justification for making it really easy to do from the UI. Out of the 7477 herbaria in the system, only 1629 have any associated observations, and only 746 have more than one. Beyond that, the embedded location creation UI seems to be wonky. I can create this herbarium through the Create Fungaria UI and I can create the location itself through the create location UI. It’s only when it’s embedded in the Create Observation UI that it gets weird. I did a screen capture showing the weirdness and uploaded it through Slack since it's too big for GitHub.

I think i've resolved the Location-name-editing issue @mo-nathan discovered as well as we can.

In terms of Google Maps API's responses, our constraint here is that when we're geolocating a place name, Google only returns one (what they deem the “BEST MATCHING PLACE”) unless we use their Places API and spend an order of magnitude more credits per request.

With lat/lngs, the situation is different. Google freely returns an array of matching locations of descending specificity, and we sift through them to only show the types of locations we are interested in.

But when geolocating a place name, we don’t get any choice. If Google picks a street address, as it does when we enter

Data Library & Archives, McLean Laboratory, Woods Hole Oceanographic Institution Quissett Campus

and Google returns

360, Woods Hole Road, Woods Hole, Falmouth, Barnstable Co., Massachusetts, USA

all we can do is remove the street number component from the hash of address components. This will not change the bounding box, which is still that of the street number/address.

@mo-nathan I noticed incidentally that the mysterious number "1531" is also appended to the location if you try to geolocate "Quissett Campus" as an observation location on main, currently.

UPDATE It's the ZIP+4 code. Adding this to the list of keys ignored in recomposing addresses.

@mo-nathan @JoeCohen

I revised the PR description at the top with the actual priorities motivating all this work, and a description of what's reusable. Realized the original description overemphasized the fungarium creation aspect, which I agree is not very important or valuable.

Going to go ahead and merge this.